1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect

Wiki

Clone wiki

connect / What Does Logout Mean?

View History

What Does Logout Mean?

Michael Jones and Brock Allen.

Mike Jones explained using his presentation that the purpose of this session is to capture what"logout" means in different contexts. The output of this session is to be used to create a document explaining "single logout" semantics. (It is also related to https://bitbucket.org/openid/connect/issues/984.)

The topics he explained were: * Differences in logout mechanisms * Reasons for performing logout * Kinds of Logout Messages in Federated Systems * Communication mechanisms for logout messages * Possible state clean-ups at RPs * Possible state clean-ups at IdPs * Logout and Auditing Information * Problems Delivering Browser-based Logout Messages * Problems Delivering Back-Channel Logout Messages

For "Problems Delivering Browser-based Logout Messages" the audience suggested to add the following three: + Computer crash, Browser crash. + State synchronization failure + Old browsers that do not have modern communication mechanisms

For "Problems Delivering Back-Channel Logout Messages", two questions came in: Q. Hard or Soft logout? A. Hard logout. Q. Sequential issues? Logout in progress while you are login in? What happens? A. Non-deterministic.

Then, Mike explained various logout scenarios, noting that the user expectations need to be taken into account.

  • Monolithic Application (No federation)
  • Single IdP, Web App RPs
  • Single IdP, Native Client with Embedded Browser
  • Single IdP, Native Client with System Browser
  • Federation Scenario with B2B
  • Federation Scenario with Social Login
  • Federated Logout (Notification to Federation Gateway from Upstream IdP)
  • Public Kiosk
  • User Inactivity in Browser
  • Account Termination
  • Account Compromise

Some of the items above had some discussion.

Single IdP, Native Client with System Browser

  • Users usually do not want to logout of the app. User expectation may be different from Web case.
  • Vladimir: There is a technical problem as well. No way to communicate from the server to the app in general.
  • John Graham-Cumming: Reset application Logout by some of the events.
  • Hannes: Anything different in device flow/IoT like applications?
  • Mike: It has not been considered.
  • John: Subtleties around the notion of login depending on the kind of client. For a device like printers, just revoking refresh token is good enough.
  • John: Native apps "login" is also different. It probably means the refresh token revocation and blows up the local context with the next access.
  • Tony: There are complications in the private mode of different browsers. It introduces completely different cookie jar.

Federation Scenario with B2B

  • When Mike asked "Should we trigger logout of upstream business partner IdP?", Hannes asked if the SecEvent token relevant here. Mike replied that SecEvent Token is a data format, which is one of the building blocks.

Federation Scenario with Social Login

  • Mike explained that it is doubtful if the upstream partner should also be logged out, as consumers are used to always being logged into social. i.e., it would be against the user expectations.
  • Nat also pointed out that if you do that, one can easily launch a denial of service attack.
  • Further, Vladimir noted that it would have some privacy implications, e.g., an actual event of logging out leaks information.

Federated Logout (Notification to Federation Gateway from upstream IdP)

  • John pointed out that it is more complex than it may seem. Think of a case where IdP (e.g. Google) sending logout message -- What RP should do? Just tear down the browser session? Blow out the App state? Just remove the refresh token from the App on the device? Should it blow out all the tokens in all the devices? Etc. A lot of thought needs to put in to figure out the user expectation.

Public Kiosk

  • Mike noted that good one should do a hard reset.

User Inactivity in Browser

  • Mike noted that inactivity is very difficult to coordinate across all RPs and IDP.
  • Dave pointed out that there is a "90 days SCA restriction" in PSD2 but how should this "90 days" are measured is up to some interpretation. Mike pointed out that it will be a business decision and not a technical decision.

Account Termination

  • In addition to what Mike has noted, Hannes pointed out that not only the tokens stored at IdP but also the tokens stored in the clients should be revoked.

Account Compromise

  • Shares initial characteristics with Account Termination?
  • Resume normal status after account recovery process & login

Other types of considerations

Then the participants discussed if there are other

Device Transfer

  • Nat pointed out that we should also consider the case of device transfer where all sorts of the state are stored locally on the device.

Account Suspension

  • Neil: Pointed out that detecting suspicious activity could suspend the account and thus may trigger logout actions.

Apps uninstall

  • It was also pointed out that one should consider what "app uninstall" should trigger.

Multi-level "logout."

  • It was also pointed out that "logout" may not be all or nothing. It may just mean to revoke some privileges. e.g., Amazon removing the ability to "check-out" from the session.

What does logout mean?

  • It is complicated, and it is not the one size fits all situation. Meeting user expectations are fundamental.

Volunteers to review the document

The following people volunteered to review the document.

  • David Kitchen (Cloudflare) dkitchen@cloudflare.com @buro9
  • Marcos Sanz (DENIC eG) sanz@denic.de
  • Vittorio Bertola

Updated